Despite the best efforts of software developers, software programs inevitably fail at one time or another. One type of failure is a crash. A crash occurs while a program module is running and results in the suspension of operation of the program module. Crashes are, among other things, frustrating to the users and in some cases may cause the user to lose work already performed. Software developers make every effort to “debug” the software programs before the programs are sold in the retail environment. Once in the retail environment, efforts are made to locate and fix any bugs in the software, especially those that result in a crash of the program. One problem in fixing the bug or bugs that cause the crash is the limited information that is given to the software developer. Often, the software developer will merely be informed that the program crashed. This limited information makes it difficult to ascertain the cause of the crash and to develop a solution.
In the development process for the software, developers will often add trace statements into the software code. These trace statements are used to generate a log of the program activity while the program is running. The trace log is a human-readable text file that informs the developer of the events taking place in the program. When a crash occurs in the development process, the trace log is used to diagnose the cause of the crash. This diagnostic procedure is made easier by using the trace log to determine not only what was happening at the exact moment of the crash, but also what events took place leading up to the crash. Prior to sending the program out into the retail environment, however, the trace statements are compiled out of the code. Even if not compiled out of the code, it would be inefficient to use the trace log as a method of diagnosing and fixing bugs in the retail version of the software program. Because the trace log is a human readable text file, it is very large. The size of the log therefore hinders its use as a diagnostic tool in the retail environment use because it would be time-consuming to send back to the developer.
To gather more information about a crash in the retail version, different approaches have been taken. For example, America Online has the ability to determine the location of a crash of Microsoft Corporation's “INTERNET EXPLORER” web browser and to report this information to Microsoft. However, other information regarding the state of a user's machine at the time of the crash is not known and it is difficult to distinguish between crashes having different origins. Without this information, it is difficult to determine if there is a bug, and if so, to correct the bug.
Another proposed solution is Microsoft Corporation's “DR. WATSON.” This program can be used to capture primitive information about a program. This primitive information is written to a text file and stored on the user's computer. The problem is that the user must know that such a text file exists, and then must forward it to the software developer to develop a solution. In addition, the information provided is not as comprehensive as the trace log used in the development stage, so it is still difficult for the software developer to properly diagnose the problem.
Yet another proposed solution is the “WATSON” program from Microsoft Corporation. WATSON captures more information than DR. WATSON, and the information is not written to a text file. Instead, the information is captured in a mini-dump, which is in a binary format that a debugger program can open and read directly. The information collected is basically a snapshot of the program at the time of the crash. Information such as the module that was running, its version, the system configuration and the system state can be collected. WATSON then gives the user the option to convey the captured information back to the software company, in this case Microsoft Corporation. WATSON also allows other specified files to be attached to the file transferred to the software company. The problem with WATSON is that the developer will only see a snapshot of the program at the time of the crash. As a developer, the information obtained from WATSON may reveal a number of different paths the program could have taken to get to the point of the crash. Just as likely, the developer may face a situation where it cannot be determined what path the program took in getting to the crash. In other words WATSON information does not reveal the events taking place within the program leading up to the crash.
Therefore, there is a need for a method that allows a developer to author programs that contain debugging systems in a retail version of the program, which are later usable by the developer to fix a bug, without creating a large bulk of data on the user's machine. There is also a need for such a method that additionally allows sensitive user information to be filtered prior to any information being sent from the user to the developer.